home *** CD-ROM | disk | FTP | other *** search
Text File | 1993-07-15 | 67.9 KB | 1,563 lines |
- The drawings contained in this Recommendation have been done in AUTOCAD
- 18.6.5 Find naming context procedure
- 18.6.5.1 Introduction
- Figure 8/X.518 shows this procedure in the form of a diagram. Below is a
- textual description. In this it is assumed that the current value of Operation
- Progress is always returned upon exit of the procedure.
- 18.6.5.2 Arguments
- The procedure makes use of the following arguments:
- - the target object name (the purported name);
- - operation progress.
- 18.6.5.3 Results
- There are two cases of successful outcome.
- The first of these returns:
- - a reference;
- - operation progress (updated appropriately).
- The second of these returns:
- - an indication that a suitable naming context was found locally;
- - operation progress (updated appropriately).
- 18.6.5.4 Errors
- One of the following errors may be returned:
- - ServiceError (unableToProceed);
- - ServiceError (invalidReference).
- 18.6.5.5 Procedure
- 1) If nameResolutionPhase is set to completed on entry, attempt to match
- the purported name against the context prefixes of the superior naming
- contexts of all the locally held naming contexts. If a match is found,
- return all the appropriate locally held naming contexts. If no match is
- found, return an invalidReference ServiceError.
- 2) If nameResolutionPhase is not set to completed, attempt to match
- context prefixes against a sequence of one or more RDNs in the initial
- portion of the purported name. For a match to be found, all RDNs in a
- context prefix must be matched. The context prefixes used are those of
- Naming Contexts for which this DSA has administrative authority. In
- case of multiple matches the one with the maximum number of matched
- RDNs is chosen.
- If a match is found, execute (3).
- If a match is not found, execute (5).
- 3) If nameResolutionPhase is notStarted, execute (4). If the number of
- RDNs in the initial portion of the purported name, matched as described
- in (2) above, is greater or equal to the nextRDNToBeResolved component
- of OperationProgress, then execute (4), otherwise execute (9).
- 4) The nextRDNToBeResolved is set to the number of matched RDNs plus 1 and
- the nameResolutionPhase is set to Proceeding. The context is returned
- and this procedure terminated.
- As a performance enhancement, the DSA may optionally match the
- purported name against the cross references held by the DSA. If more
- RDNs are matched against a cross reference than against the locally
- held context prefixes, then execute step (7).
- Note - The Name Resolution procedure will in case of this outcome call
- the Local Name Resolution.
- 5) If no match was found, the value of the nameResolutionPhase is checked.
- If the nameResolutionPhase is notStarted, execute (6).
- If the nameResolutionPhase is proceeding or completed, then
- execute (9).
- 6) Using Cross Reference context prefixes, attempt to match against a
- sequence of one or more RDNs in the initial portion of the purported
- name. In case of multiple matches, the one with the maximum number of
- matched RDNs is chosen.
- 7) If a match was found to a cross reference, set the nextRDNToBeResolved
- to the number of RDNs in the chosen cross reference. The cross
- reference is returned and this procedure is terminated.
- 8) If no match was found to a cross reference, determine if the DSA is a
- first level DSA. If not, it will have a superior reference. Return
- this and terminate the procedure.
- If the DSA is a first level DSA, set nextRDNToBeResolved to one, and
-
-
-
-
- Fascicle VIII.8 - Rec. X.518 PAGE1
-
- nameResolutionPhase to proceeding. Return the root naming context and
- terminate the procedure.
- 9) Check the value of the referenceType component of the ChainingArgument.
- If a non-specific subordinate reference was used, or the request came
- from a DUA, execute (10); otherwise, return ServiceError with
- invalidReference problem and terminate the procedure.
- 10) Compare the initial portion of the purported name to the context
- prefixes (minus their last RDN) of the locally held naming contexts.
- This effectively is a comparison to some of the naming contexts of the
- immediate superior to this DSA.
- f there is no match, return ServiceError with invalidReference problem
- and terminate the procedure.
- f a match is found, and the number of RDNs matched is less than in
- nextRDNToBeResolved - 1, return ServiceError with invalidReference
- problem; otherwise, return ServiceError unableToProceed problem.
- Terminate the procedure.
- 18.6.6 Local Name Resolution
- 18.6.6.1 Introduction
- The Local Name Resolution matches RDNs in the purported name against
- internal knowledge references. It returns Found, Remote Reference, Alias
- Dereferenced, or Error indication.
- Figure 9/X.518 shows this procedure in the form of a diagram. Below is a
- textual description.
- 18.6.6.2 Arguments
- The procedure makes use of the following arguments:
- - internal reference to naming context (with pointer to the entry whose
- name is the same as the context prefix);
- - the target object name (the purported name);
- - operation progress;
- - the value of the dontDereferenceAliases service control;
- - the value of the aliasedRDNs parameter;
- - the value of the aliasDereferenced parameter.
- 18.6.6.3 Results
- There are three cases of successful outcome.
- The first of these returns:
- - a reference;
- - operation progress (updated appropriately).
- The second of these returns:
- - an indication that the entry was found locally;
- - operation progress (updated appropriately).
- The third of these returns:
- - an indication that an alias was dereferenced;
- - operation progress (set back to "not started").
- 18.6.6.4 Errors
- One of the following errors may be returned:
- - name error.
- 18.6.6.5 Procedure
- The naming context returned by FindNaming Context will point to the entry
- of the root of the subtree. In the case of the root context, the entry is only a
- null entry.
- 1) f the internal reference is for an alias entry, execute step (7),
- otherwise step (2).
- 2) f all the RDNs in the purported name have been matched, then the target
- entry has been found. Set nameResolutionPhase to completed. An internal
- pointer is returned and the procedure terminated.
- Otherwise step (3) should be executed.
- Note - The matching could be attained with the context prefix on its
- own, or with the context prefix plus successive RDNs contained in
- internal references in the knowledge tree.
- 3) If an internal reference entry is found subordinate to the current
- entry in the knowledge tree which matches the next RDN in the purported
- name, then increment the nextRDNToBeResolved, set current entry to
- subordinate entry, and execute step (1) of this procedure again.
- 4) If the current entry has a subordinate reference whose RDN matches the
- next one in the purported name, return it and terminate the procedure.
-
-
-
-
- PAGE16 Fascicle VIII.8 - Rec. X.518
-
- 5) If there are any non-specific subordinate references, subordinate to
- the current entry in the knowledge tree, return them as references and
- terminate the procedure.
- 6) If an internal reference, subordinate reference, or non-specific
- subordinate reference is not found, then check the number of RDNs in
- the purported name that have been matched. If more RDNs have been
- matched than in the aliasedRDNs component of ChainingArgument, then
- return NameError with noSuchObject problem. If less RDNs have been
- matched, then return NameError with aliasProblem.
- 7) If the number of RDNs in the purported name that have been matched is
- less than or equal to the aliasedRDNs component of ChainingArgument (if
- any), then the previous alias that was dereferenced (if any) points to
- another alias. If so, return NameError with aliasDereferencingProblem.
- 8) If the aliasedRDNs component is missing, or if the number of RDNs
- matched is greater than aliasedRDNs component of ChainingArgument, then
- check the dontDereferenceAlias service control. If aliases can be
- dereferenced, then execute step (9), otherwise step (10).
- 9) Dereference the alias. Set nameResolutionPhase of OperationProgress to
- notStarted. Set aliasDereferenced component of ChainingArgument to
- TRUE, and aliasedRDNs to the number of RDNs in the aliasedObjectName
- attribute of the alias entry. Set targetObject to the new name.
- Terminate the procedure. (The process of Name Resolution will be
- restarted.)
- 10) If all the RDNs in the purported name have been matched, execute step
- (2). Otherwise, return NameError with aliasDereferencingProblem.
- 18.7 Object evaluation procedures
- The object evaluation procedures specified comprise two categories of
- procedures:
- a) single-object evaluation procedure;
- b) multiple-object evaluation procedures.
- Figure 10/X.518 shows the object evaluation procedure.
- FIGURE 10/X.518 - T0704600-88
-
- 18.7.1 Single-object evaluation procedures
- Single-object evaluation procedures, which are common to the class of
- operations concerned with accessing a single object are carried out directly,
- with the result or error being returned to the invoker.
- These operations comprise Read, Compare, AddEntry, RemoveEntry,
- ModifyEntry and ModifyRDN, and their Chained counterparts.
- The action required on the entry is as described in the appropriate
- paragraph of Recommendation X.511.
- AddEntry, RemoveEntry, and ModifyRDN operations affect knowledge. If the
- immediate superior of the entry is in a different DSA, correct external knowledge
- references shall be maintained. How this is done is outside the scope of this
- Recommendation.
- How the DSA is chosen to contain the entry created by AddEntry is outside
- the scope of this Recommendation.
- If the immediate superior of an entry to be created by AddEntry or
- modified by ModifyRDN has non-specific subordinate references, procedures outside
- the scope of this Recommendation shall be followed to ensure that no two entries
- have the same distinguished name.
- Requests which cannot be satisfied under these conditions shall fail with
- an UpdateError with problem affectsMultipleDSAs.
- 18.7.2 Multiple-object evaluation procedures
- Multiple-object evaluation procedures, which are common to the class of
- operations concerned with accessing multiple objects, are specified in the
- following subparagraphs.
- These operations comprise List and Search, and their Chained counterparts.
- 18.7.2.1 List
- This paragraph specifies the evaluation procedure specific to List and
- ChainedList. (In what follows the term "List" applies to both.)
- 18.7.2.1.1 List procedure (I)
- This procedure applies where the List request has nameResolutionPhase
- component of OperationProgress set to notStarted or proceeding and where the DSA,
- after performing Name Resolution The base object will be denoted by "e".
-
-
-
-
- Fascicle VIII.8 - Rec. X.518 PAGE1
-
- 1) Get each locally held immediate subordinate of e to form a local set of
- results. Set aliasEntry and fromEntry in ListResult as appropriate.
- 2) Get the set of non-specific subordinate references and subordinate
- references to DSAs which hold immediate subordinates of "e".
- 3) Pass the subrequest with base object = e, and OperationProgress set to
- completed to the Operation Dispatcher which subsequently forwards it to
- each DSA which holds immediate subordinates of e.
- Note - If the DSA holds subordinate references with an indication of
- whether or not the subordinate entry are aliases, and the dontUseCopy is FALSE,
- then this step can be omitted for those entries. The information about the
- subordinates is available directly.
- 18.7.2.1.2 List Procedure (II)
- This procedure applies to a List request with the nameResolutionPhase
- component of OperationProgress set to completed.
- The base object will be denoted by "e".
- 1) Get each locally held immediate subordinate of e to form a local set of
- results. Set aliasEntry and fromEntry in ListResult as appropriate.
- 2) Pass the results to the Operation Dispatcher which forwards them to the
- requesting DUA or DSA.
- 18.7.2.2 Search
- This paragraph specifies the evaluation procedure specific to Search and
- ChainedSearch. (In what follows the term "Search" applies to both.)
- Note that two circumstances exist, requiring two separate procedures. The
- first procedure ( 18.7.2.2.1) applies when the DSA executing the Search contains
- the targetObject as a local entry. The second procedure ( 18.7.2.2.2) applies
- when the DSA executing the Search does not hold the targetObject, but only
- subordinates of the targetObject.
- 18.7.2.2.1 Search procedure (I)
- This procedure applies to a Search request with the nameResolutionPhase
- component of OperationProgress set to notStarted or proceeding and where the DSA,
- after performing Name Resolution, determines that it holds the target object.
- The base object will be denoted by "e".
- 1) If the subset argument is baseObject or wholeSubtree, then apply the
- filter argument specified in the Search to the entry e, to form a set
- of local results. Return the results for Results Merging. If the subset
- argument is baseObject, terminate the procedure, otherwise continue at
- (2).
- 2) If the subset argument is oneLevel or wholeSubtree form a set E from
- the locally-held immediate subordinates of e, except that:
- If aliases are to be dereferenced, i.e. the searchAliases parameter is
- TRUE, then any alias entries that are found are handled in paragraph 5)
- below and do not contribute to these results.
- Apply the filter arguments to E to give a filtered subset Ew'gE; return
- this set Ew' of local results for Results Merging.
- 3) Other subordinates of e may reside in other DSAs, and if so will be
- referenced as subordinate or non-specific subordinate references. For
- each DSA which is so referenced, prepare a new Search with targetObject
- = e, and with nameResolutionPhase of OperationProgress set to
- completed. Return each Search subrequest to the Operation Dispatcher
- for forwarding. If any error result is returned from a subrequest, it
- is ignored, as if no subrequest had been sent.
- 4) If the subset argument is oneLevel, the Search is now complete so
- terminate the procedure.
- If the subset argument is wholeSubtree, then:
- if the set E from paragraph (2) is empty, then the whole subtree held
- in this DSA has been searched, so terminate the procedure;
- otherwise continue processing as follows:
- let each entry that was in set E be denoted by e. Repeat the Search
- procedure from paragraph (2), for each entry e.
- 5) If aliases are to be dereferenced, any alias entries found in step (2)
- are placed in set D. For each entry d in D, dereference the alias, and
- formulate a new Search with nameResolutionPhase set to notStarted, and
- targetObject created from the aliasedObjectName attribute and the old
- targetObject name.
- If the subset argument was oneLevel, set it to baseObject in the new
-
-
-
-
- PAGE16 Fascicle VIII.8 - Rec. X.518
-
- subrequest, otherwise set it to wholeSubtree.
- If any error result is returned from the subrequest, it is ignored, as
- if no subrequest had been made.
- 18.7.2.2.2 Search Procedure (II)
- This procedure applies to a Search request with the nameResolutionPhase
- component of OperationProgress set to completed.
- The target object will be denoted by "e".
- For each locally held immediate subordinate ew' of e, formulate a new
- request with targetObject = ew'.
- If the subset argument was oneLevel, set it to baseObject, otherwise leave
- it as wholeSubtree. Now carry out the procedure defined in steps (1) to (5) in
- 18.7.2.2.1. If there are no such subordinates, return unableToProceed
- ServiceError.
- 18.8 Result merging procedure
- This procedure is called when external results and/or errors are present.
- There might also be one internal result. All results and errors are assumed to be
- held within the DSA until the procedure completes.
- The external information could be due to chaining, multicasting or request
- decomposition.
- In the case of chaining there will be a single result or error. In the
- case of multicasting there might be either no result, one result or several
- identical results. In addition, there may be some errors. If there is more than
- one result, all but one of them are arbitrarily discarded. A result is always
- returned in preference to an error. If there are no results, an error is
- returned, with the following exceptions:
- i) If invalidReference was returned, the reference is marked as such, and
- the DSA may either use an appropriate alternate external reference to
- continue the request, or return ditError to the requestor. (The
- handling of invalid external references is beyond the scope of this
- Recommendation.)
- ii) In the case of multicasting, unableToProceed errors should be ignored,
- unless all responses are of this type in which case NameError
- noSuchObject should be returned to the responder. If at least one
- result is returned, then all errors can be ignored.
- iii) In the case of referrals, these need not be treated as errors, and
- may be acted upon.
- If the merging is required due to a request decomposition, the merging
- amounts to forming the union of the results.
- In the case of decomposition, when there are both results and errors to be
- merged, an incomplete result is returned to the requestor.
- A DSA might at this stage choose to extract referrals from the incoming
- results and errors that should be merged. It might then decide to explore all or
- some of these further, in which case operations are chained. The old result will
- have to be saved and later merged with the results or errors produced by the
- chaining.
- The handling of signatures which may be present with the results being
- returned is specified in 18.9.2 below.
- 18.9 Procedures for distributed authentication
- This paragraph specifies the procedures necessary to support the directory
- distributed authentication services. These services, and hence the procedures,
- are categorized as:
- - originator authentication, which is supported in either an unprotected
- (simple identity based) or secure (based upon digital signatures) form;
- and
- - results authentication which is similarly protected (again based upon
- digital signatures).
- 18.9.1 Originator authentication
- 18.9.1.1 Identity based authentication
- The identity based authentication service enables DSAs to authenticate the
- original requestor of information for the purpose of effecting local access
- controls. DSAs wishing to exploit this service must adopt the following
- procedure:
- - for a DSA requiring to authenticate a DAP request, the DSA acquires
- the distinguished name of the requestor through the Bind procedures at
- the time a DUA association (DUA or DSA) is established. Successful
-
-
-
-
- Fascicle VIII.8 - Rec. X.518 PAGE1
-
- conclusion of these procedures does not in any way prejudice the level
- of authentication that may subsequently be required for processing
- operations using that association;
- - the DSA with which the DUA association exists must insert the
- requestor's distinguished name in the initiator field of the
- ChainingArgument for all subsequent chained operations to other DSAs;
- - a DSA, on receiving a chained-operation, may satisfy that operation, or
- not, depending upon the determination of access rights (a locally
- defined mechanism). If the outcome is not satisfactory a SecurityError
- may be returned with SecurityProblem set to insufficientAccessRights.
- 18.9.1.2 Signature-based originator authentication
- This signature-based originator authentication service enables a DSA to
- authenticate (in a secure manner) the originator of a particular service request.
- The procedures to be effected by a DSA in realizing this service are described in
- this paragraph.
- The signature-based authentication service is invoked by a DUA using the
- SIGNED variant of an optionally-signed service request.
- A DSA, on receiving a signed request from another DSA, shall remove that
- DSA's signature prior to processing the operation. Assuming the result of any
- signature verification proves to be satisfactory, the DSA will continue to
- progress the operation. If, during processing, the DSA requires to perform
- chaining, multicasting or request decomposition, the argument set for each
- associated chained operation shall be constructed as follows:
- - the DSA forms an argument set which may be optionally signed; the
- argument set comprises the incoming signed argument set together with a
- modified ChainingArgument.
- In the event that the DSA is able to contribute information to the
- response, originator authentication, based upon the signed service request, may
- be used for the determination of access rights to that information.
- If a DSA receives an unsigned service request for information which will
- only be released subject to originator authentication, a SecurityError will be
- returned with SecurityProblem set to protectionRequired.
- 18.9.2 Results authentication
- This service is provided to enable requestors of directory operations
- (either DUA or DSAs) to verify (in a secure manner using digital signature
- techniques) the source of results. The results authentication service may be
- requested irrespective of whether originator authentication is to be used.
- The results authentication service is initiated using the signed value of
- the protectionRequest component as contained within the argument set of directory
- operations; a DSA receiving an operation with this option selected may then
- optionally sign any subsequent results. The signed option in the
- protectionRequest serves as an indication, to the DSA, of the requestor's
- preference; the DSA may, or may not, actually sign any subsequent results.
- In the case where a DSA performs chaining, multicasting or request
- decomposition of such a request, the DSA has a number of options in terms of the
- form of results sent back to the requestor, namely:
- a) return a composite response (signed or unsigned) to the requestor;
- b) return a set of two or more uncollated partial responses (signed or
- unsigned) to the requestor; within this set zero or more members may be
- signed and zero or one unsigned. In the event that an unsigned partial
- result is present, this member may in fact be a collation of one or
- more unsigned partial responses which have been received from other
- DSAs, contributed by this DSA, or both.
- ANNEX A
- (to Recommendation X.518)
- ASN.1 for distributed operations
- This Annex is part of the Recommendation.
- This Annex includes all of the ASN.1 type, value and macro definitions
- contained in this Recommendation in the form of the ASN.1 module Distributed
- Operations.
- DistributedOperations {joint-iso-ccitt ds(5) modules(1)
- distributedOperations(3)}
- DEFINITIONS ::=
- BEGIN
- EXPORTS
-
-
-
-
- PAGE16 Fascicle VIII.8 - Rec. X.518
-
- DirectoryRefinement, chainedReadPort, chainedSearchPort,
- chainedModifyPort,
- DSABind, DSABindArgument,
- DSAUnbind,
- ChainedRead, ChainedCompare, ChainedAbandon,
- ChainedList, ChainedSearch,
- ChainedAddEntry, ChainedRemoveEntry,
- ChainedModifyEntry, ChainedModifyRDN,
- DsaReferral, ContinuationReference;
- IMPORTS
- InformationFramework, abstractService, distributedOperations,
- directoryObjectIdentifiers, selectedAttributeTypes
- FROM UsefulDefinitions {joint-iso-ccitt ds(5) modules(1)
- usefulDefinitions(0)}
- DistinguishedName, Name, RelativeDistinguishedName
- FROM InformationFramework informationFramework
- id-ot-dsa, id-pt-chained-read, id-pt-chained-searc , id-pt-chained-
- modify
- FROM DistributedDirectoryObjectIdentifiers,
- distributedDirectoryObjectIdentifiers
- PresentationAddress
- FROM SelectedAttributeTypes selectedAttributeTypes
- directory, readPort, searchPort, modifyPort
- DirectoryBind,
- ReadArgument, ReadResult,
- CompareArgument, CompareResult,
- Abandon
- ListArgument, ListResult,
- SearchArgument, SearchResult,
- AddEntryArgument, AddEntryResult,
- RemoveEntryArgument, RemoveEntryResult,
- ModifyEntryArgument, ModifyEntryResult,
- ModifyRDNArgument, ModifyRDNResult,
- Abandoned, AttributeError, NameError, ServiceError, SecurityError,
- UpdateError
- OPTIONALLY-SIGNED, SecurityParameters
- FROM DirectoryAbstractService directoryAbstractService
- -- objects and ports --
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.8 - Rec. X.518 PAGE1
-
- DirectoryRefinement ::= REFINE directory AS
- dsa RECURRING
- readPort [S] VISIBLE
- searchPort [S] VISIBLE
- modifyPort [S] VISIBLE
- chainedReadPort PAIRED WITH dsa
- chainedSearchPort PAIRED WITH dsa
- chainedModifyPort PAIRED WITH dsa
- dsa OBJECT
- PORTS { readPort [S],
- searchPort [S],
- modifyPort [S],
- chainedReadPort,
- chainedSearchPort
- chainedModifyPort}
- ::= id-ot-dsa
- chainedReadPort PORT
- ABSTRACT OPERATIONS {
- ChainedRead, ChainedCompare,
- ChainedAbandon}
- ::= id-pt-chained-read
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE16 Fascicle VIII.8 - Rec. X.518
-
- chainedSearchPort PORT
- ABSTRACT OPERATIONS {
- ChainedList, ChainedSearch}
- ::= id-pt-chained-search
- chainedModifyPort PORT
- ABSTRACT-OPERATIONS {
- ChainedAddEntry, ChainedRemoveEntry,
- ChainedModifyEntry, ChainedModifyRDN}
- ::= id-pt-chained-modify
- DSABind ::= ABSTRACT-BIND
- TO {chainedRead,
- chainedSearch,
- chainedModify}
- DirectoryBind
- DSAUnbind ::= UNBIND
- FROM {chainedRead,
- chainedSearch,
- chainedModify}
- -- operations, arguments and results --
- ChainedRead ::=
- ABSTRACT-OPERATION
- ARGUMENT OPTIONALLY-SIGNED SET{
- ChainingArgument,
- [0] ReadArgument}
- RESULT OPTIONALLY-SIGNED SET{
- ChainingResult,
- [0] ReadResult}
- ERRORS {
- DsaReferral, Abandoned, AttributeError, NameError,
- ServiceError, SecurityError}
- ChainedCompare ::=
- ABSTRACT-OPERATION
- ARGUMENT OPTIONALLY-SIGNED SET{
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.8 - Rec. X.518 PAGE1
-
- ChainingArgument,
- [0] CompareArgument}
- RESULT OPTIONALLY-SIGNED SET{
- ChainingResult,
- [0] CompareResult}
- ERRORS {
- DsaReferral, Abandoned, AttributeError, NameError,
- ServiceError, SecurityError}
- ChainedAbandon ::= Abandon
- ChainedList ::=
- ABSTRACT-OPERATION
- ARGUMENT OPTIONALLY-SIGNED SET{
- ChainingArgument,
- [0] ListArgument}
- RESULT OPTIONALLY-SIGNED SET{
- ChainingResult,
- [0] ListResult}
- ERRORS {
- DsaReferral, Abandoned, AttributeError, NameError,
- ServiceError, SecurityError }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE16 Fascicle VIII.8 - Rec. X.518
-
- ChainedSearch ::=
- ABSTRACT-OPERATION
- ARGUMENT OPTIONALLY-SIGNED SET{
- ChainingArgument,
- [0] SearchArgument}
- RESULT OPTIONALLY-SIGNED SET{
- ChainingResult,
- [0] SearchResult}
- ERRORS {
- DsaReferral, Abandoned, AttributeError, NameError,
- ServiceError, SecurityError}
- ChainedAddEntry ::=
- ABSTRACT-OPERATION
- ARGUMENT OPTIONALLY-SIGNED SET{
- ChainingArgument,
- [0] AddEntryArgument}
- RESULT OPTIONALLY-SIGNED SET{
- ChainingResult,
- [0] AddEntryResult}
- ERRORS {
- DsaReferral, Abandoned, AttributeError, NameError,
- ServiceError, SecurityError, UpdateError}
- ChainedRemoveEntry ::=
- ABSTRACT-OPERATION
- ARGUMENT OPTIONALLY-SIGNED SET{
- ChainingArgument,
- [0] RemoveEntryArgument}
- RESULT OPTIONALLY-SIGNED SET{
- ChainingResult,
- [0] RemoveEntryResult}
- ERRORS {
- DsaReferral, Abandoned, NameError,
- ServiceError, SecurityError, UpdateError}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.8 - Rec. X.518 PAGE1
-
- ChainedModifyEntry ::=
- ABSTRACT-OPERATION
- ARGUMENT OPTIONALLY-SIGNED SET{
- ChainingArgument,
- [0] ModifyEntryArgument}
- RESULT OPTIONALLY-SIGNED SET{
- ChainingResult,
- [0] ModifyEntryResult}
- ERRORS {
- DsaReferral, Abandoned, AttributeError, NameError,
- ServiceError, SecurityError, UpdateError}
- ChainedModifyRDN ::=
- ABSTRACT-OPERATION
- ARGUMENT OPTIONALLY-SIGNED SET{
- ChainingArgument,
- [0] ModifyRDNArgument}
- RESULT OPTIONALLY-SIGNED SET{
- ChainingResult,
- [0] ModifyRDNResult}
- ERRORS {
- DsaReferral, Abandoned, NameError,
- ServiceError, SecurityError, UpdateError}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE16 Fascicle VIII.8 - Rec. X.518
-
- -- errors and parameters --
- DSAReferral ::=
- ABSTRACT-ERROR
- PARAMETER SET {
- [0] ContinuationReference,
- contextPrefix [1] DistinguishedName OPTIONAL}
- -- common arguments/results --
- ChainingArguments ::= SET {
- originator [0] DistinguishedName OPTIONAL,
- targetObject [1] DistinguishedName OPTIONAL,
- operationProgress [2] OperationProgress DEFAULT
- {notStarted}
- traceInformation [3] TraceInformation,
- aliasDereferenced [4] BOOLEAN DEFAULT FALSE,
- aliasedRDNs [5] INTEGER OPTIONAL,
- -- absent unless aliasDereferenced is TRUE
- returnCrossRefs [6] BOOLEAN DEFAULT FALSE,
- referenceType [7] ReferenceType DEFAULT superior,
- info [8] Domaininfo OPTIONAL,
- timeLimit [9] UTCTime OPTIONAL,
- [10] SecurityParameters DEFAULT { }}
- ChainingResults ::= SET {
- info [0] Domaininfo OPTIONAL,
- crossReferences [1] SEQUENCE OF CrossReference OPTIONAL,
- [2] SecurityParameters DEFAULT { }}
- CrossReference ::= SET {
- contextPrefix [0] DistinguishedName,
- accessPoint [1] AccessPoint}
- ReferenceType ::= ENUMERATED {
- superior (1),
- subordinate (2),
- cross (3),
- nonSpecificSubordinate (4)}
- TraceInformation ::= SEQUENCE OF
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.8 - Rec. X.518 PAGE1
-
- SEQUENCE {
- targetObject Name,
- dsa Name,
- OperationProgress}
- OperationProgress ::= SET {
- nameResolutionPhase [0] ENUMERATED {
- notStarted (1),
- proceeding (2),
- completed (3)},
- nextRDNToBeResolved [1] INTEGER OPTIONAL}
- DomainInfo ::= ANY
- ContinuationReference ::= SET {
- targetObject [0] Name,
- aliasedRDNs [1] INTEGER OPTIONAL,
- operationProgress [2] OperationProgress
- rdnsResolved [3] INTEGER OPTIONAL,
- referenceType [4] ReferenceType OPTIONAL,
- -- only present in the DSP --
- accessPoints [5] SET OF AccessPoint }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE16 Fascicle VIII.8 - Rec. X.518
-
- AccessPoint ::= SET {
- ae-title [0] Name,
- address [1] PresentationAddress }
- ANNEX B
- (to Recommendation X.518)
- Modelling of knowledge
- This Annex is not part of the Recommendation.
- B.1 Example of knowledge modelling
- The following example illustrates the knowledge information that would
- have to be maintained by the DSAs shown in Figure 5/X.518 ( 9). Figure 5/X.518
- depicts a hypothetical DIT logically partitioned into five Naming Contexts (A, B,
- C, D and E) and physically distributed over three DSAs (DSA1, DSA2, DSA3). In the
- example, DSA1 holds context C, DSA2 holds contexts A, B, and E, and DSA3 holds
- context D.
- The following abbreviations have be n used in Figures B-1/X.518 to B-
- 3/X.518.
- SUPR: superior reference
- SUBR: subordinate reference
- INTR: internal reference
- NSSR: non-specific subordinate reference
- CROSSR: cross reference
- DSAn: Distinguished Name of DSAn
- PS: Presentation Address
- CP: context prefix
- RDN: Relative Distinguished name
- DSA: Distinguished name of a DSA
- PTR: Pointer
- AON: Aliased Object Name.
- Note - The following figures are intended only to provide a pictorial
- example of the concepts defined in this paragraph. How knowledge information is
- actually stored and managed in a particular DSA implementation is a local matter
- and is outside the scope of this Recommendation.
- FIGURE B-1/X.518 - T0704610-88
-
- Figure B-1/X.518 illustrates the knowledge information that must be held
- by DSA1. This must include the following context prefixes and set of references:
- Context Prefixes: {C=WW, O=ABC}, context C.
- Cross References: { }
- Superior References: {DSA2, presentation address of DSA2}
- Internal References
- for Context C: {C=WW, O=ABC},
- {OU=G}, {OU=H}
- {OU=G, CN=1},
- {OU=G, CN=m},
- {OU=G, CN=n}.
- Subordinate References: { }
- Non-specific subordinate
- References: {DSA2, presentation address of DSA2}.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.8 - Rec. X.518 PAGE1
-
- FIGURE B-2/X.518 - T0704620-88
-
- Figure B-2/X.518 illustrates the knowledge information that must be held
- by DSA2. This must include the following context prefixes and set of references:
- Context Prefixes: {C=WW}, context A
- {C=VV}, context B
- {C=WW}, O=ABC, OU=I}, context E.
- Cross References: { }
- Superior References: { }
- Internal References
- for Context A: {C=WW}
- Internal References
- for Context B: {C=VV}
- Internal References
- for Context E: {C=WW, O=ABC, OU=I},
- {CN=o},
- {CN=p},
- {CN=q}.
- Subordinate References
- for Context A: {C=WW, O=ABC}
- Subordinate References
- for Context B: {C=VV, O=DEF}
- Non-specific subordinate
- References: { }
- FIGURE B-3/X.518 - T0704630-88
-
- Figure B-3/X.518 illustrates the knowledge information that must be held
- by DSA3. This must include the following context prefixes and set of references:
- Context Prefixes: {C=VV, O=DEF}, context D
- Cross References: {{C=WW, O=ABC, OU=H}, DSA1, presentation address of DSA1}
- (not shown in the figure above)
- Superior References: {DSA2, presentation address of DSA2}
- Internal References
- for Context D: {DSA1, presentation address of DSA1}
- {C=VV, O=DEF},
- {OU=J},
- {OU=K} alias for {C=WW, O=ABC, OU=I, CN=o}
- (alias information is not part of the knowledge)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE16 Fascicle VIII.8 - Rec. X.518
-
- Subordinate References: { }
- Non-specific subordinate
- References: { }
- B.2 Example of distributed name resolution
- The following is an example of how Distributed Name Resolution is used to
- process different directory requests. The example is based on the hypothetical
- DIT shown in Figure 5/X.518 ( 9) and the corresponding DSA configuration(s) shown
- in Figures B-1/X.518 to B-3/X.518 (Annex B).
- Assuming a chaining mode of propagating, the following requests addressed
- to DSA1 would be processed as follows:
- 1) A request with distinguished name {C=WW, O=ABC, OU=G, CN=1}
- - Will match context prefix {C=WW, O=ABC} of context C for which DSA1
- has administrative authority. Therefore, name resolution will begin
- in DSA1 with context C.
- - Name resolution will proceed downwards in context C successfully
- matching each remaining RDN, until CN=1 is located.
- 2) A request with distinguished name {C=WW, O=JPR}
- - Will not match any context prefix held by DSA1, therefore DSA1 will
- use its superior reference to forward the request to its superior
- DSA, DSA2.
- - In DSA2, the request will match context prefix {C=WW} and name
- resolution will begin in DSA2 with context A.
- - Name resolution will not find a subordinate of C=WW to match RDN
- O=JPR, therefore the request will fail and the name will be
- determined to have been invalid (i.e. reference a non-existent
- object).
- 3) A request with distinguished name {C=VV, O=DEF, OU=K}
- - DSA1 will therefore forward the request to its superior DSA, DSA2.
- - The request will match context prefix {C=VV} of context B held by
- DSA2. Therefore, name resolution will begin in DSA2 with context
- B.
- - As name resolution attempts to match O=DEF, it will find a
- subordinate reference indicating that {C=VV, O=DEF} is the start of
- a new context held in DSA3.
- - Name resolution will continue in DSA3 until {C=VV, O=DEF, CN=K} is
- located.
- - Assuming that aliases are to be dereferenced, a new name will be
- constructed using the aliased name contained in the entry {C=VV,
- O=DEF, CN=K}. The resulting new name will be: {C=WW, O=ABC, OU=I,
- CN=o}.
- - DSA3 will resume processing of the request using the new name
- obtained by dereferencing.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.8 - Rec. X.518 PAGE1
-
- ANNEX C
- (to Recommendation X.518)
- Distributed use of authentication
- This Annex is not part of the Recommendation.
- C.1 Summary
- The security model is defined in 10 of Recommendation X.501. The
- following is a summary of the main points of the model.
- a) Simple Authentication of the operation initiator is not supported in
- the DSP.
- b) Strong Authentication, by the signing of the request and of the result,
- is supported in the DSP.
- c) Encryption of the request, or of the result, is not supported in the
- DSP.
- d) Authentication of errors, including referrals, is not supported in the
- DSP.
- This Annex describes how b) above is realized in the distributed
- Directory. It makes use of terminology and notation defined in Recommendation
- X.509.
- C.2 Simple authentication
- The DUA will be authenticated as part of the Bind Operation of the DAP.
- Thereafter, only the name of the DUA will be carried in the DSP, in the initiator
- field of the Chaining Argument.
- C.3 Distributed authentication model
- FIGURE C-1/X.518 - T0704640-88
-
- Figure C-1/X.518 illustrates the model to be used to specify the
- distributed authentication procedures. The model identifies the sequence of
- information flows for the general case of a list or search operation. The
- operation is considered as originating from DUA "a" citing a target object which
- resides in DSA "c"; in performing the operation, DSAs "b", "c", "d" and "e" are
- to be involved.
- DUA "a" initially contacts any DSA (DSA "b") which does not hold the
- target object, but which is able to navigate, via chaining, to the DSA (DSA "c")
- holding the target object. If all the DSAs were operating in referral mode, then
- the model would be significantly simplified, and each DUA/DSA exchange would
- equate, in authentication terms, to the interaction between DUA "a" and DSA "b".
- C.4 DUA to DSA
- Originator authentication is realized as a consequence of exchange (1). In
- Figure C-1/X.518 the authentication procedure is as follows:
- Let
- OA = the Operation Argument i.e. Search, Read, Compare etc. Argument as
- defined in Part 3.
- and
- a(OA) = the Operation Argument signed by DUA "a".
- Authentication will be determined by verification of the signature.
- C.5 Transference from the DAP to the DSP
- This procedure is effected by DSA "b" in Figure C-1/X.518 and represents
- the transference of the signed identity of the initiator from the DAP to the DSP.
- DSA "b" formulates the appropriate Chaining Argument as described in 12.3
- of this Recommendation and combines it with the Operation Argument from the DAP
- thus forming a Chained Operation, i.e. Chained Read, Search, List etc. of the
- DSP. The Chained Operation so formed will be signed prior to passing it to other
- DSAs (DSA "c" in Figure C-1/X.518). The data structure can be represented as:
- b{ChA,a{OA}} = the Chained Operation signed by
- DSA b
- where
- ChA = Chaining Argument.
- Authentication information carried in the DSP between two DSAs [labelled
- exchange (2) in Figure C-1/X.518] therefore comprises two parts:
- - the Operation Argument, signed by the initiator, which allows
- authentication of the initiator;
- - the Chained Operation, signed by the sending DSA, which allows
- authentication of the sending DSA.
- C.6 Chaining through intermediate DSAs
- This procedure would be effected by DSA "c" in the model depicted in
-
-
-
-
- PAGE16 Fascicle VIII.8 - Rec. X.518
-
- Figure C-1/X.518. DSA "c" will discard the signature provided by the sending DSA
- (DSA "b" in Figure C-1/X.518), and will modify the Chaining Argument, as
- described in 12.3 of this Recommendation. DSA "c" shall then combine the
- modified Chaining Argument with the signed Operation Argument, and sign the
- result to create a modified signed Chained Operation. This can be represented by:
- c{ChAw', a{OA}} = the Chained Operation signed by DSA "c"
- where
- ChAw' = modified Chaining Argument.
- This procedure would be effected by DSA "c" in the model depicted in
- Figure C-1/X.518. DSA "c" upon the nature of the operation, and upon the type of
- knowledge held, DSA "c" may perform request decomposition prior to chaining or
- multicasting any resultant operation(s). This has been represented n Figure C-
- 1/X.518 by DSA "c" sending operations to DSA "d" and DSA "e"; in each case the
- authentication procedure is identical.
- C.7 Results authentication
- The results authentication service is requested by an initiator of a
- directory operation using the signed option within the protectionRequest
- SecurityParameter. In providing a response to such a request a DSA may optionally
- decide whether or not to sign any or all of the results; the results
- authentication service does not provide for the authentication of error
- responses.
- Within the context of a particular DSA processing results from an
- arbitrary number of DSAs (each of which are associated with a particular service
- request) the following distinct cases are possible:
- - the DSA provides a complete set of results for an operation without the
- need to perform any collating function (represented by DSA "d" and DSA
- "e" in Figure C-1/X.518);
- - the DSA collates local results (sourced by this DSA) with the results
- from one or more other DS s (represented by DSA "c" in Figure C-
- 1/X.518);
- - the DSA chains a result from a DSA to either another DSA or a DUA and
- does not contribute to the result set as it does so (represented by DSA
- "b" in Figure C-1/X.518).
- C.7.1 DSA results - no collation
- This paragraph addresses the role of a DSA in being the sole source of
- results to a particular operation request, i.e. the DSA has no collation function
- to perform. The paragraph considers the case for both the DSP and the DAP.
- C.7.1.1 DSP
- The DSA can choose to perform either of the following procedures:
- - return the results unsigned, this can be represented by:
- ChR,OR = Chained Operation Result (unsigned)
- where
- ChR = Chaining Results
- OR = Operation Result;
- - sign only the Operation Result, this can be represented by:
- ChR, d(OR) = Operation Result signed by DSA "d";
- - sign only the Chained Operation Result, which can be represented as:
- d (ChR, OR) = Chained Operation Result signed by DSA "d"
- - sign both the Operation Result and the Chained Operation Result, which
- can be represented by:
- d{ChR, D{OR}} = Operation Result and Chained Operation Result signed by
- DSA "d".
- Note - For the case where the Operation Result is signed, the signed
- result will be carried back to the initiator; for the case where the Chained
- Operation Result has been signed, the receiving DSA will have to discard the
- signature in order to modify the Chaining Results argument prior to forwarding
- the Chained Operation Result.
- C.7.1.2 DAP
- This is fully described in Recommendation X.511, a summary is reproduced
- here for completeness.
- The DSA can choose to either return the results unsigned, which can be
- represented by:
- OR = Operation Result
- or, signed, which can be represented by:
- d{OR} = Operation Result signed by DSA "d".
-
-
-
-
- Fascicle VIII.8 - Rec. X.518 PAGE1
-
- C.7.2 DSA results - collation included
- This paragraph addresses the role of a DSA in returning the result of
- particular service requests where collation and integration of results from other
- DSAs is a necessary prerequisite. The paragraph considers the case for both the
- DSP and the DAP.
- C.7.2.1 DSP
- Recognizing that zero or more results received from other DSAs may be
- signed, this procedure enables a DSA to collate and integrate the results and
- sign zero or more constituent parts of the composite result and optionally, sign
- the composite result as a whole.
- C.7.2.1.1 Production of the chaining results argument
- This procedure requires that a DSA (represented by D A "c" in Figure C-
- 1/X.518) remove all of the Chained Operation Result signatures from the results
- received from external DSAs (DSA "d" and DSA "e" in Figure C-1/X.518). DSA "c"
- then possesses a set of unsigned Chaining results, a set of signed Operation
- Results, and a set of unsigned Operation Results.
- All the Chaining Results are manipulated as described in 12.4 of this
- Recommendation to create a single modified Chaining Result, denoted by:
- i) ChRw' = modified Chaining Results.
- C.7.2.1.2 Unsigned locally derived result
- If the DSA does not wish to sign the locally generated results, the set of
- unsigned Operation Results are merged with the local result to form a modified
- set of Operation Results, denoted by:
- ORw' = Merged Operation Result.
- The complete set of Operation Results is then the union of the set of
- externally signed Operation Results denoted by:
- d{OR}, e{OR} ...
- and the Merged Operation Result, collectively denoted by:
- (ii) ORw', d{OR}, e{OR} ...= Operation Result.
- C.7.2.1.3 Signed locally derived result
- If the DSA does wish to sign the locally generated results, then the
- externally generated set of unsigned Operation Results are first merged together.
- The complete set of Operation Results is then the union of the locally signed set
- of Operation Results denoted by C{OR}, the merged set of externally unsigned
- Operation Results denoted by, OR", and the set of externally signed Operation
- Results denoted by:
- d{OR}, e{OR}, ..., which are collectively denoted as:
- (iii) c{OR}, ORw", d{OR}, e{OR}, ... = Operation Result.
- C.7.2.1.4 Unsigned chained operation result
- If the DSA does not wish to sign the Chained Operation Result, then the
- latter will comprise the Chaining Results (identified in (i) above) added to the
- Operation Result identified in either (ii) or (iii) above, collectively, these
- are denoted by:
- either:
- ChRw', ORw', d{OR}, e{OR}, ... = Chained Operation Result (unsigned).
- or,
- ChRw', c{OR}, OR", d{OR}, e{OR}, ... = Chained Operation Result
- (unsigned) and Operation
- Result signed by DSA "c".
- C.7.2.1.5 Signed chained operation result
- If the DSA does wish to sign the Chained Operation Result, then the result
- will comprise the Chaining Results (identified in (i) above) added to the
- Operation Result (identified in either (ii) or (iii) above), collectively denoted
- as:
- either:
- c{ChRw', ORw', d{OR}, e{OR}, ...} = Chained Operation Result signed by DSA
- "c"
- or,
- c{ChRw', c{OR}, ORw", d{OR}, e{OR}, ...} = Chained Operation Result
- and Operation
- Result signed by DSA "c".
- C.7.2.2 DAP
- The procedure is very similar to that described in C.7.2.1, with the
- exception that the Chaining Results argument is not passed in the DAP.
- C.7.3 DSA chained results
-
-
-
-
- PAGE16 Fascicle VIII.8 - Rec. X.518
-
- This paragraph addresses the procedures to be effected by a DSA in
- chaining an operation result back to the requestor, DSA or DUA, within the DSP
- and DAP respectively.
- C.7.3.1 DSP
- The DSA initially removes the signature (if one exists) from the Chained
- Operation Result. It then manipulates the Chaining Results argument as described
- in this Recommendation, to produce a modified Chaining Results argument. The
- latter is then merged back with the Operation Result argument to produce a
- modified Chained Operation Result. Finally, the DSA may optionally sign the
- Chained Operation Result before passing it to the next DSA in the chain.
- C.7.3.2 DAP
- A DSA (represented by DSA "b" in Figure C-1/X.518) first removes the
- signature (if one exists) from the Chained Operation Result. It then analyses and
- discards the Chaining Results argument and, finally, it optionally signs the
- remaining Operation Result argument before passing the result to the DUA.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.8 - Rec. X.518 PAGE1
-
- ANNEX D
- (to Recommendation X.518)
- Distributed directory object identifiers
- This Annex is part of the Recommendation.
- This Annex includes all of the ASN.1 object identifiers contained in this
- Recommendation in the form of the ASN.1 module
- DistributedDirectoryObjectIdentifiers.
- DistributedDirectoryObjectIdentifiers {joint-iso-ccitt ds(5) modules(1)
- distributedDirectoryObjectIdentifiers(13)}
- DEFINITION ::=
- BEGIN
- EXPORTS
- id-ot-dsa id-pt-chainedRead, id-pt-chainedSearch, id-pt-
- chainedModify;
- IMPORTS
- id-ot, id-pt
- FROM UsefulDefinitions {joint-iso-ccitt ds(5) modules(1)
- usefulDefinitions(0)};
- -- objects --
- id-ot-dsa OBJECT IDENTIFIER ::= {id-ot 3}
- -- part types --
- id-pt-chainedRead OBJECT IDENTIFIER ::= {id-pt 4}
- id-pt-chainedSearch OBJECT IDENTIFIER ::= {id-pt 5}
- id-pt-chainedModify OBJECT IDENTIFIER ::= {id-pt 6}
- END
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE16 Fascicle VIII.8 - Rec. X.518
-
-